1. The Field of the Invention
The present invention relates generally to ensuring data integrity within a networking box, and more particularly, to on-chip clock and data recovery in a transceiver module.
2. Background of the Invention
The proliferation and significance of networking technology is well known. The ever-increasing demand for network bandwidth has resulted in the development of technology that increases the amount of data traveling across a network. Advancements in modulation techniques, coding algorithms and error correction have drastically increased rates of this data. For example, a few years ago, the highest rate that data could travel across a network was at approximately one Gigabit per second (Gb/s). This rate has increased ten-fold today where data travels across Ethernet and SONET (Synchronous Optical Network) networks at upwards of 10 Gb/s. For instance, the XFP (10 Gb/s serial electrical interface) Pluggable Module Multi-Source Agreement is directed at transceivers operating at approximately 10 Gb/s.
FIG. 1 illustrates some of the shortcomings of a transceiver module 100 commonly used in prior art networking devices. The transceiver module 100 is coupled to a network via interfaces 130, 135 and to a host device 105 such as a media access controller (‘MAC’) card or SONET framer. The transceiver module 100 has a receiver 115 that is coupled to network interface 130 and a first serializer/deserializer (‘SERDES’) 110. The first SERDES 110 is coupled to the host 105 via a parallel bus 140. An example of this parallel bus 140 may be a (XAUI) 10-Gigabit Attachment Unit Interface that has four 3.125 Gb/s channels that transfer an aggregate 10 Gb/s data stream between the transceiver module 100 and the host 105. The transceiver module 100 also has a transmitter 125 that is coupled to network interface 135 and a second SERDES 120. The second SERDES 120 is coupled to the host 105 via a second parallel bus 145 such as the XAUI described above.
In operation, a serial optical data stream received by the transceiver module 100 is converted to an electrical serial data stream by the receiver 115. This electrical serial data stream is deserialized by the SERDES 110 into four channels and transmitted via the parallel bus 140 to the host 105 for processing. This deserialization occurs in order to prevent further bandwidth degradation of the electrical data stream and stay below a jitter budget as it continues to travel along the data path. A high data rate electrical signal (e.g., 10 Gb/s) is more easily distorted by imperfections within the data path and by the inductance of the bus and connections along the data path. Reflections caused by discontinuities within a transmission line and amplitude degradations caused by nodes within a path (e.g., wire bond, solder bump, etc.) may significantly increase errors within the signal and increase jitter beyond an acceptable threshold or budget. Additionally, inductance is proportionally more severe at higher frequencies. Thus, the data stream is deserialized onto parallel transmission lines in order to reduce the rate on each of these lines and minimize degradation along the data path.
A similar deserialization occurs on the transmit side of the transceiver module 100 for the same reasons described above. In particular, a deserialized electrical data stream is transferred from the host 105 to the second SERDES 120 via parallel bus 145. The second SERDES 120 serializes this electrical signal. The transmitter 125 converts the serial electrical signal to an optical signal and transmits it onto the network.
One drawback of module 100 is that the SERDES 110, 120 and the interfaces to the parallel buses 140, 145 require a relatively large amount of space on the transceiver module 100. Additionally, SERDES consume power and release a relatively large amount of heat. Another drawback of module 100 is that conventional transceiver modules do not include convenient, cost-effective means to monitor the status of data paths and confirm proper operation of the transceiver.
Fiberoptic modules operating at data rates less than 10 Gb/s commonly employ serial electrical interfaces without any means of resetting the jitter budget at the inputs and outputs of the module 100. The most common data rates for these modules are at 1.0625 Gb/s for Fibre Channel, 1.25 Gb/s for Gigabit Ethernet, 2.125 Gb/s for double-rate Fibre Channel, 2.48 Gb/s for OC-48, 2.7 Gb/s for forward error correction (‘FEC’) rates of OC-48, and numerous rates less than 1 Gb/s for other applications. Serial modules are also used for proprietary links at data rates from less than 1 Gb/s to about 3.125 Gb/s. At these relatively low data rates, there is no need to perform reshaping or retiming of the data at the electrical inputs and outputs (‘I/Os’) of the module because the signal degradations at those data rates are sufficiently small. However, at data rates approaching or exceeding 10 Gb/s, the bit periods become sufficiently short so that signal degradations are difficult to minimize using conventional approaches to serial modules. Additionally, serial modules at data rates lower than 10 Gb/s can have digital or analog monitoring functions, but the types of error monitoring or diagnostic features that are possible in a module incorporating an integrated SERDES have not thus far implemented.
Moreover, the XFP standard requires that transceiver modules handle data rates of approximately 10 Gb/s, while outputting to the host through a serial interface among other things. Particularly, an XFI (10 Gb/s serial electrical interface) is designed for serial input from an XFP transceiver. This allows host designers and manufacturers to supply host systems assuming that XFP transceivers will perform the discussed functions.
Therefore, it is desirable to provide a transceiver module capable of handling 10 Gb/s data input from a network within a jitter budget. It is further desirable to provide a transceiver module that interfaces with a host using serial connections, thereby allowing the removal of SERDES components from the module. Additionally, it is desirable to provide additional functionality, for example error monitoring functionality that is integrated within the transceiver module that would identify errors and perform bit error rate tests (‘BERTs’) within a data path and/or component on the module.